RD 做完一天的工作，可以拿出 commit、PR、程式碼；但 QA 呢？

如果今天沒有找到 Bug，難道就代表沒有產出？如果只拿「執行了 80 個 Test Case、通過率 95%」來證明工作，又真的能說明測試品質嗎？

測試真正有價值的地方，往往不是「跑了多少案例」，而是測試人員看了哪些風險、用了什麼策略、如何判斷結果，以及過程中發現了什麼。

這也是 SBTM 想解決的核心問題：不要只管理測試文件，而是讓測試這個思考活動本身變得可見、可解釋、可管理。

從「工件」回歸「活動」

傳統的測試管理往往是基於工件（Artifact-based）的。這意味著管理層關注的是文件：有多少測試案例？執行了多少？通過率是多少？在這種模式下，測試人員很容易淪為「填表機器」，工作的價值被簡化為數字。

SBTM 則提出了截然不同的觀點：它是一種基於活動（Activity-based）的方法。測試是一種思維活動（Thinking Activity）和意義建構（Sense-making）**的過程。測試不應只是標記「完成」或「未完成」。

在測試過程中，你需要做判斷、做決策，並且應對那些在測試開始前無法預知的變化。這些都需要批判性思考，而這些思考過程是無法完全被編碼在僵化的測試文件中的。

在SBTM這個框架下，我們不再計算「案例」，而是管理Session。

• Session 的定義：一段受控的時間（Time-boxed），在此期間測試人員全神貫注地執行特定的測試活動。

• Charter（憲章）：每個 Session 都有一個明確的目標，我們稱之為 Charter。這是在開始測試前就構思好的方向。

• 報告與筆記（Reporting & Note-taking）： 測試人員需要在測試過程中做筆記並撰寫報告。這不僅是為了記錄結果，更是為了「展示工作內容」。

• 匯報/解說（Debriefing）： 這是測試負責人（Lead）與測試人員之間的對談。討論測試過程、使用的策略、遇到的困難以及發現的風險。這是一個教學相長的過程，負責人可以通過提問來指導測試人員提升技能。

• 頻率： 原創始人建議每天進行，但實際執行上可以根據團隊狀況靈活調整。

• 度量指標（Metrics）：雖然可以測量時間分配（例如：設置時間 vs. 測試時間），但這些數字通常被視為次要的，主要用於輔助管理或滿足管理層對數據的需求。

• 保護測試人員：
  此框架提供了一種「形式感（Formality）」，能夠保護測試人員的核心工作，讓他們有空間進行探索性測試，同時又能滿足管理層對可見度與問責制的要求。

• 靈活調整：
  SBTM 並非僵化的「最佳實踐（Best Practice）」，而是一個可以根據團隊具體情況進行調整的模型。James Bach 強調，使用者應該理解其設計初衷，然後根據自己的需求進行修改（例如調整匯報頻率或度量方式）。

• 問責制（Accountability）：
  雖然強調情境驅動（Context-driven）和靈活性，但測試人員必須對自己的選擇負責，能夠解釋為什麼選擇這種測試策略。

這個框架將測試視為一種受過訓練的探索活動，它通過設定明確的任務（Mission），在限定的時間Session內進行高強度的思維活動，並通過筆記和匯報來確保測試品質與策略的有效性，而不是單純依賴測試案例的數量來衡量進度。

如何利用 SBTM 向管理層展示測試價值

以任務為導向的（SBTM）能夠有效解決「探索性測試難以管理」的迷思，並透過具體化、結構化的方式向管理層展示測試價值。以下是具體的策略與方法：

(1) 提供「有意義的數據」作為折衷方案，而非計算測試案例
管理層通常需要數字來獲得安全感，但計算測試案例的個數，往往無法反映真實價值。SBTM 提供了替代方案：

• 以「時間」與「Session」作為度量單位：
  當客戶或管理層要求計算測試案例時，SBTM 允許團隊拒絕這種無效指標，改以「Session 數量」或「花費的時間」作為交付數據。這是一種有效的折衷方案，既滿足了管理層對指標的需求，又保留了測試團隊的專業自主權。

• 設定「經驗法則」來管理預期：
  當管理層詢問「今天做了 5 小時的 Session 是多還是少？」時，可以設定了一個簡單的標準：測試人員每天約一半時間（半天）進行 Session 測試，另一半時間用於會議或其他事務。只要數據達到這個基準線，管理層就會感到安心，不再過度糾結於細節。

(2) 將隱性的測試工作「具象化」（Tangibility）
程式設計師有程式碼來展示他們做了什麼，測試人員也應該有東西來展示我們的工作。

在傳統模式下，如果沒有發現 Bug，測試人員的一天似乎就「沒做什麼」。但在 SBTM 中，Session Report（測次報告）測試筆記就是你的「程式碼」。

• 展示工作內容（Show Your Work）：
  透過撰寫 Session 報告與筆記，測試人員能夠像開發人員展示程式碼一樣，展示他們的測試軌跡。這證明了測試不僅僅是隨意點擊或單純的回報 Bug，而是一項包含策略與批判性思考的專業活動。

• 打破「黑箱」作業：
  傳統的「Pass/Fail」表格往往被用作一種「擋箭牌（Shield）」，目的是讓管理層不要過問細節。SBTM 則相反，它鼓勵透明化，讓管理層看到測試過程中的決策與發現，從而建立真正的信任。

(3) 利用「形式感（Formality）」建立專業信任
SBTM 提供了一種結構化的外觀，這對管理層來說非常重要：

• 保護測試團隊的「柔軟核心」：
  James Bach 形容 SBTM 能夠保護測試人員。透過建立一套有紀律的報告與匯報機制（Formality），管理層會認為團隊是有組織、有計畫的。這種「形式感」能作為一種保險，讓管理層放心放手，使測試人員在 Session 內部擁有自由探索的空間,。

• 主動式防禦：
  與其等待管理層施壓要求寫測試案例，不如主動實施 SBTM。這樣當管理層詢問進度時，你已經有一套完整的文檔和體系可以展示，從而避免被強加不合理的管理方式。

(4) 強調「當責性（Accountability）」與策略解釋
SBTM 強調測試是一種基於情境（Context-driven）的選擇，這能向管理層展示更高的專業度：

• 解釋「為什麼」：
  使用 SBTM 的測試人員不只是盲目執行，而是需要對自己的策略負責。當管理層詢問為何選擇某種測試方式時，測試人員能夠解釋背後的邏輯與風險評估，而不僅僅是說「我感覺想這樣測」。這種能夠解釋決策的能力，是展示專業價值的關鍵。

• 深入了解產品狀態：
  對於測試經理而言，閱讀 Session 報告和進行匯報（Debriefing）能讓他們即使不親自測試，也能對產品的真實狀態有深刻的了解，這比單純看通過率的數字更有管理價值。

總結來說，利用 SBTM 向管理層展示價值的核心在於：用「結構化的報告」取代「測試案例計數」，用「策略性的解釋」取代「沈默的執行」，讓測試工作變得可見、可解釋且可管理。

參考文獻
Session Based Test Management: Interview with Djuka Selendic - James Bach
https://www.youtube.com/watch?v=l1fpjtwnoXQ

核心實踐——筆記與匯報

(1) 筆記（Note-taking）：大腦的延伸

很多人抗拒寫筆記，但這是不可或缺的技能。測試過程錯綜複雜，人腦很容易「迷路」。筆記能幫助你在被打斷後迅速找回狀態，或是記下稍後需要調查的線索。

一位測試人員曾因為害怕寫筆記而選擇晚上回家加班測試。這顯示了缺乏技能帶來的壓力。但一旦掌握，筆記反而能消除壓力，因為你不需要把所有細節都硬記在腦子裡。

如果測試人員抗拒寫筆記（Session Notes）或報告，通常不是因為他們懶惰，而是因為缺乏技能或恐懼。以下是建議的引導策略：

A. 理解抗拒的根源：技能缺乏與恐懼

很多測試人員從未培養過「描述測試策略」的技能。他們可能只知道執行操作，但不知道如何用專業方式來記錄他們的思考過程。

抗拒往往源於恐懼。測試人員擔心一旦寫下具體細節，就會暴露他們其實「不知道該測什麼」或缺乏測試的深度。傳統的「通過/失敗」測試案例清單常被當作一種「擋箭牌（Shield）」，用來隱藏他們實際工作的模糊性，避免管理層的質問。

B. 創造安全的學習環境（Psychological Safety）

在匯報（Debriefing）時，管理者應明確表示這是一個安全的空間。讓測試人員知道「不知道某個概念」是可以接受的，這樣他們才不會因為害怕受批評而拒絕記錄。

如果測試人員寫不出筆記，是因為他們腦中缺乏測試的「心智模型（Mental Model）」。管理者應利用匯報時間，耐心地通過提問（例如：「你用了什麼測試策略？覆蓋率（Coverage）如何？使用了哪些啟發式方法）來即時教導這些概念，幫助他們建立寫筆記所需的詞彙庫。

C. 強調對「個人」的實用價值

向測試人員解釋，筆記首先是為了幫助他們自己。測試過程中有大量資訊，人腦容易遺忘。筆記能幫助他們在被打斷後迅速找回進度，或是記錄下稍後需要調查的 Bug，從而減輕工作壓力。

引導他們將筆記視為「展示工作成果」的方式。就像程式設計師有程式碼一樣，測試筆記是測試人員展現其批判性思考與專業價值的證據，這能幫助他們贏得真正的尊重。

D. 尊重自主權，但要求當責

不要直接命令「照我說的做」。建議採用協商態度：「我希望你試試這個方法。如果你試了之後覺得行不通，請告訴我為什麼，並提出一個能解決問題的替代方案」。

如果測試人員堅持不寫筆記，他們必須能解釋他們如何解決「交代測試軌跡」和「讓工作透明化」的問題。他們不能只是因為「不想做」而拒絕，必須對自己的選擇負責。

E. 循序漸進，給予適應期

對於習慣傳統方法的測試人員，大量的新概念（Session, Charter, Metrics）會讓他們感到不知所措。建議分階段進行，例如先專注於簡單的筆記，之後再引入度量指標。

培養良好的筆記與報告技能通常需要 2 到 3 個月 的時間，管理者需要有耐心，不要期望立竿見影。

(2) 匯報（Debriefing）：教育的黃金時刻

SBTM 的靈魂不在於報告的文件本身，而在於匯報（Debriefing），即測試負責人與測試人員之間的對談。可以檢視測試品質，以及輔導測試人員的關鍵時刻。

如果測試人員在報告中只寫「這個功能可以動」或口頭回報「我測試了產品，找不出問題」。這通常是個警訊。

「這能運作」這句話對負責人來說沒有任何意義，因為它缺乏細節。如果測試人員只能說「我看了產品並尋找問題」，卻無法說明具體做了什麼，這顯示他們缺乏測試的「心智模型（Mental Model）」。James 認爲這個模型的基石，就是三個關鍵概念：Oracle（神諭）、Coverage（覆蓋率） 與 Heuristics（啟發式方法）。

A. Oracle（神諭）：你憑什麼說是 Bug？

Oracle 是「你如何知道是否存在 Bug」的機制或標準。 這與「你看了什麼」完全不同。它是關於判斷（Judgment）。當你看到一個畫面或結果時，你腦中有什麼規則告訴你「這是錯的」或「這是對的」？如果沒有 Oracle，你就只是在「看著」產品，而不是在「測試」產品。

範例

• 不明確的 Oracle： 「我覺得怪怪的。」（這只是直覺，尚未轉化為明確標準）
• 明確的 Oracle： 「這違反了產品的一致性，因為在設定頁面是 A，但在首頁顯示為 B。」或者「這違反了規格書的定義。」

以下這些問題，可以幫助測試人員確認他們是否知道 Oracle。

• 「你如何判定這是一個 Bug（或不是 Bug）？」
  你的判斷標準是什麼？是文件、常識還是與舊版本對比？
• 「為什麼這個問題很重要？（Why does that matter?）」
  訓練測試人員評估 Bug 的影響力與嚴重性。
• 「你是依賴明確的錯誤訊息，還是依賴其他的判斷依據？」
  挖掘隱性的 Oracle（例如：反應時間變慢、UI 排版異常），這是文件上不會寫的。
• 「如果系統給出了另一個結果，你會認為那是錯的嗎？」
  反向測試他們對「預期結果」的理解是否清晰。
• 「你是否區分了『我看過這個功能』（Coverage）和『我知道它是對的』（Oracle）？」
  糾正許多測試人員最常犯的觀念混淆。

B. Coverage（覆蓋率）：你到底看了哪裡？

Coverage 是指你「看過」了產品的哪些部分。 大多數人只關注「功能」，但在 SBTM 的定義中，覆蓋率包含更廣泛的維度，如數據、平台、配置等。

範例

• 功能覆蓋： 測試了「登入」按鈕。
• 數據覆蓋： 測試了「含有特殊符號」的使用者名稱。
• 配置覆蓋： 在「深色模式」或「低電量模式」下進行測試。
• 環境覆蓋： 在生產環境（Production）與測試環境（Staging）的差異。

以下這組問題的目的是拓展測試的廣度，打破只測「Happy Path」的習慣：

• 「除了功能之外，你還覆蓋了哪些配置（Settings）或環境？」
  提醒測試人員，軟體是在特定環境下運作的，配置不同結果可能不同。
• 「請告訴我你使用了什麼測試數據？」
  數據的變化（如空值、極大值）往往是發現 Bug 的關鍵。
• 「有哪些風險是你這次『故意不看』的？」
  測試不可能窮盡。這問題迫使測試人員承認並記錄他們的選擇與遺漏，這屬於測試策略的一部分。
• 「你是在什麼樣的情境下進行測試的？」
  考慮使用者當下的狀態（例如：網路不穩、多工切換中）。
• 「我們還有哪些盲點是完全沒有覆蓋到的？」
  自我檢視覆蓋率的缺口。

C. Heuristics（啟發式方法）：你的策略是什麼？

Heuristics 是你用來尋找 Bug 的「策略」或「經驗法則」。這解釋了你如何進行探索，以及你為什麼選擇這樣做。它是指引你在茫茫程式碼大海中找到 Bug 的指南針。

範例

• 工具輔助： 使用特定的攔截工具來修改封包。
• 特定攻擊模式： 專門針對輸入框進行 SQL Injection 測試，或快速點擊導致系統崩潰。
• 風險導向： 因為這個模組過去常出錯，所以針對它進行高強度測試。

下面這組問題的目的是提升測試人員的專業當責性，讓他們能解釋自己的戰術選擇。

• 「你使用了什麼啟發式方法（Heuristics）來發現這個問題？」
  將直覺轉化為可複製、可教學的方法論。
• 「使用這種方法，你覺得你可能會『錯過』什麼樣的 Bug？」
  這是極具威力的一題。它訓練測試人員批判自己的策略，了解每個方法的局限性。
• 「你為什麼選擇這個策略？（Why did you choose this?）」
  要求測試人員解釋策略背後的決策背後的因果邏輯，證明他們是針對當下情境做出的選擇，而不是盲從。你要能解釋：「在當下這個『情境』裡，為什麼 A 動作會導致 B 結果？以及為什麼你認為 B 結果比其他選項更好？」
• 「你在測試過程中如何調整了你的策略（Adapt strategy as you go）？」
  測試是動態的意義建構過程，確認他們是否根據新發現的資訊靈活應變。
• 「你是否使用了任何工具（Tools）來輔助測試？」
• 工具是延伸人類能力的槓桿，這也是啟發式方法的一環。